home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970104-19970326 / 000274_news@columbia.edu _Mon Feb 17 21:24:51 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA01746
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 17 Feb 1997 21:24:50 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA12785
  7.     for kermit.misc@watsun; Mon, 17 Feb 1997 21:24:50 -0500 (EST)
  8. Path: news.columbia.edu!panix!news.mathworks.com!uunet!in1.uu.net!204.177.184.15!everest.iserv.net!news
  9. From: mjordan@i386.jordan.org (Mark J. Jordan)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Binary script files?
  12. Date: 17 Feb 1997 21:03:06 -0500
  13. Organization: A Red Hat Commercial Linux Site
  14. Lines: 62
  15. Message-ID: <5eb2kq$4s7@i386.jordan.org>
  16. References: <5e1no6$1rb@i386.jordan.org>
  17.  <5e1u83$m06@watsun.cc.columbia.edu>
  18. Reply-To: mjordan@mail.com
  19. NNTP-Posting-Host: gr-max6-7.iserv.net
  20. X-Newsreader: NewsWerthy 2.20
  21. Xref: news.columbia.edu comp.protocols.kermit.misc:6613
  22.  
  23. In <5e1u83$m06@watsun.cc.columbia.edu>, fdc@watsun.cc.columbia.edu (Frank da
  24. Cruz) wrote:
  25. > In article <5e1no6$1rb@i386.jordan.org>,
  26. > Mark J. Jordan <mjordan@mail.com> wrote:
  27. > : I have experienced other comm programs in the past, most notably
  28. > : Procomm Plus, that will allow script files to be translated into a
  29. > : binary file. This presented two, if not other, benefits: security of
  30. > : the script code and faster execution.
  31. > :
  32. > Faster execution -- marginally, perhaps.  Some day when we have nothing
  33. > else to do, we might devote some time to producing a "compiler" for
  34. > Kermit scripts -- but there are about 1000 other priorities that are
  35. > higher, as you see by reading this newsgroup each day :-)
  36.  
  37. Absolutely understandable, Frank.
  38.  
  39. > Security -- this type of security is only illusory: "security through
  40. > obscurity".  Anybody with the time and inclination to defeat it can do
  41. > so easily.
  42.  
  43. I understand that nothing is infallible, but even to "obscure" the
  44. actual code from general eyes would be beneficial. I am contemplating
  45. a project at this time, the detials of which I'll not disclose. But
  46. the platforms involved would be many including DOS, Linux, OS/2, Win,
  47. and possibly others. Kermit is a perfect element to the overall
  48. solution due to its multiplatform existance and the project's needed
  49. telecommunication abilities. Because the remote stations will be on
  50. client PC's, I wish for them not to be able to easily read such code,
  51. and hence my interest.
  52.  
  53. > : I am interested to know if binary scripts are/will be a possibility
  54. > : for Kermit... I am curious mostly for the former capability of hiding
  55. > : the code.
  56. > : 
  57. > Which Kermit are you referring to?  In many OS's, e.g. UNIX, it is a
  58. > rather simple matter to encrypt your script, and then invoke it from a
  59. > shell script that prompts you for the key and then feeds it to Kermit.
  60.  
  61. > I assume you are concerned about keeping passwords online -- always a
  62. > risky business.  "Using C-Kermit" discusses this topic at some length.
  63.  
  64. I have the MS-DOS Kermit book... and have already inquired my local
  65. book store about the C-Kermit version. They don't have it in stock, so
  66. I ordered it about a week ago. I'll check out this section upon
  67. receipt.
  68.  
  69. I am not so much interested in keeping passwords online as I will have
  70. a very restricted dialup connection, possibly running Kermit's remote
  71. mode with pretty much everything disabled except to receive files.
  72.  
  73. I suppose the inline encrytion example you gave would work nicely. Its
  74. just a matter of finding one that will be buildable on all related
  75. platforms... something of a DES (data encryption standard) nature would
  76. be best... anyone w/ideas, more than happy to here them 8^).
  77.  
  78. > - Frank
  79.  
  80. ---------------------------------------------------------------------
  81. Mark J. Jordan, President                      
  82. Par Computer Solutions, Grand Rapids, MI
  83. mjordan@mail.com
  84. ---------------------------------------------------------------------